NAME¶

sssd-secrets - Відповідач реєстраційних даних SSSD

ОПИС¶

На цій сторінці довідника описано налаштування засобу надання відповідей Secrets для sssd(8). Щоб дізнатися більше про синтаксис налаштування, зверніться до розділу «ФОРМАТ ФАЙЛІВ» сторінки довідника sssd.conf(5).

У багатьох програмах системи або користувача існує потреба у збереженні конфіденційних даних, зокрема паролів і ключів до служб, та зручній роботі з цими даними. Простим способом вирішення цієї проблеми є вбудовування цих “реєстраційних даних” до файлів налаштувань. Втім, це призводить до потенційного розширення доступу до конфіденційних даних через резервні копії, системи керування налаштуваннями, та загалом робить захист даних важчим.

Проєкт custodia[1] було створено для урегулювання цієї проблеми у хмароподібних середовищах, але нам ця ідея здалася вартою уваги навіть на рівні окремої ізольованої системи. Як служба захисту, SSSD є ідеальним місцем для реалізації такої можливості з доступом до відповідного програмного інтерфейсу через сокети UNIX. Така реалізація уможливлює використання локальних викликів і належну маршрутизацію до локального або віддаленого сховища ключів, зокрема сховища IPA, для зберігання, депонування і відновлення даних.

Записи реєстраційних даних є простими парами ключ-значення. Реєстраційні дані кожного з користувачів співвідносяться із його простором назв на основі ідентифікатора користувача. Це означає, що реєстраційні дані одного користувача ніколи не потраплять до іншого. Реєстраційні дані зберігаються у “контейнерах”, які можна вкладати один у одного.

Оскільки відповідач реєстраційних даних може використовуватися ззовні для зберігання загальних реєстраційних даних, як це описано у решті цієї сторінки підручника, і всередині іншими компонентами SSSD для зберігання власних реєстраційних даних, можна налаштувати деякі параметри, зокрема квоти для окремих записів “hive” у підрозділі налаштувань із назвою відповідного рою. Підтримувані у поточній версії рої:

secrets

kcm

КОРИСТУВАННЯ ВІДПОВІДАЧЕМ РЕЄСТРАЦІЙНИХ ДАНИХ¶

Сокет UNIX, на якому відповідач SSSD очікує на дані, розташовано у /var/run/secrets.socket.

Відповідач для реєстраційних даних активується за допомогою сокетів systemd(1). На відміну від інших відповідачів SSSD, його не можна запустити додаванням рядка “secrets” до інструкції “service”. Модуль сокета systemd називається “sssd-secrets.socket”, а відповідний файл служби має назву “sssd-secrets.service”. Щоб службу можна було активувати за допомогою сокета, слід увімкнути і задіяти сокет, а потім увімкнути службу:

systemctl start sssd-secrets.socket
systemctl enable sssd-secrets.socket
systemctl enable sssd-secrets.service


            

Будь ласка, зауважте, що відповідні налаштування модулів вже могло бути виконано засобами вашого дистрибутива.

ПАРАМЕТРИ НАЛАШТУВАННЯ¶

Відповідачу реєстраційних даних можна передавати типові параметри відповідача SSSD, зокрема “debug_level” та “fd_limit”. Із повним списком параметрів можна ознайомитися на сторінці підручника sssd.conf(5). Крім того, передбачено декілька специфічних для реєстраційних даних параметрів.

Відповідач реєстраційних даних налаштовується за допомогою загального розділу “[secrets]” і необов'язкових розділів “[secrets/users/$uid]” для окремих користувачів у sssd.conf. Будь ласка, зауважте, що деякі параметра, зокрема тип постачальника даних, можна вказати лише у підрозділах окремих користувачів.

provider (рядок)

Наведені нижче параметри стосуються лише записів реєстраційних даних “hive” і тому їх слід встановлювати у підрозділах окремих роїв. Встановлення значення параметра 0 означає «без обмежень».

containers_nest_level (ціле значення)

max_secrets (ціле значення)

max_uid_secrets (ціле число)

max_payload_size (ціле значення)

Наприклад, щоб встановити різні квоти для роїв “secrets” та “kcm”, скористайтеся такими рядками:

[secrets/secrets]
max_payload_size = 128
[secrets/kcm]
max_payload_size = 256


            

Вказані нижче параметри стосуються лише конфігурацій, у яких використовується засіб надання даних “proxy”.

proxy_url (рядок)

auth_type (рядок)

auth_header_name (рядок)

auth_header_value (рядок)

forward_headers (список рядків)

verify_peer (булеве значення)

verify_host (булеве значення)

capath (рядок)

cacert (рядок)

cert (рядок)

key (рядок)

КОРИСТУВАННЯ API REST¶

У цьому розділі наведено список доступних команд та приклади користування із використанням програми curl(1). Усі запити до засобу надання даних проксі мають встановлювати для заголовка Content Type значення “application/json”. Крім того, для локального засобу надання даних передбачено підтримку встановлення для Content Type значення “application/octet-stream”. Реєстраційні дані, збережені із запитами, де встановлено значення заголовка Content Type “application/octet-stream”, є даними у кодуванні base64 у сховищі, які розшифровуються під час отримання, тому не можна зберігати реєстраційні дані із одним значенням Content Type і отримувати з іншим. Адреса реєстраційних даних має починатися з /secrets/.

Отримання списку реєстраційних даних

curl -H "Content-Type: application/json" \


     --unix-socket /var/run/secrets.socket \


     -XGET http://localhost/secrets/


                        

Отримання реєстраційних даних

curl -H "Content-Type: application/json" \


     --unix-socket /var/run/secrets.socket \


     -XGET http://localhost/secrets/foo


                        

curl -H "Content-Type: application/octet-stream" \


     --unix-socket /var/run/secrets.socket \


     -XGET http://localhost/secrets/bar


                        

Встановлення реєстраційних даних

curl -H "Content-Type: application/json" \


     --unix-socket /var/run/secrets.socket \


     -XPUT http://localhost/secrets/foo \


     -d'{"type":"simple","value":"foosecret"}'


                        

curl -H "Content-Type: application/octet-stream" \


     --unix-socket /var/run/secrets.socket \


     -XPUT http://localhost/secrets/bar \


     -d'barsecret'


                        

Створення контейнера

curl -H "Content-Type: application/json" \


     --unix-socket /var/run/secrets.socket \


     -XPOST http://localhost/secrets/mycontainer/


                        

http://localhost/secrets/mycontainer/mysecret


                        

Вилучення реєстраційних даних або контейнера

curl -H "Content-Type: application/json" \


     --unix-socket /var/run/secrets.socket \


     -XDELETE http://localhost/secrets/foo


                        

ПРИКЛАД НАЛАШТОВУВАННЯ МОДУЛІВ НАДАННЯ ДАНИХ CUSTODIA І ПРОКСІ¶

Для тестування засобу надання даних «proxy» вам слід налаштувати проксі-передавання на сервер Custodia. Будь ласка, завжди користуйтеся документацією до Custodia, оскільки інструкції налаштовування у різних версіях Custodia можуть бути різними.

Ці налаштування визначають для сервера Custodia адресу очікування даних http://localhost:8080, дозволяють будь-кому із заголовком із назвою MYSECRETNAME, який встановлено у значення mysecretkey, обмін даними із сервером Custodia. Запишіть ці дані до файла (наприклад, custodia.conf):

[global]
server_version = "Secret/0.0.7"
server_url = http://localhost:8080/
auditlog = /var/log/custodia.log
debug = True
[store:simple]
handler = custodia.store.sqlite.SqliteStore
dburi = /var/lib/custodia.db
table = secrets
[auth:header]
handler = custodia.httpd.authenticators.SimpleHeaderAuth
header = MYSECRETNAME
value = mysecretkey
[authz:paths]
handler = custodia.httpd.authorizers.SimplePathAuthz
paths = /secrets
[/]
handler = custodia.root.Root
store = simple


            

Далі, віддайте команду custodia, вказавши файл налаштувань у параметрі командного рядка.

Будь ласка, зверніть увагу на те, що у поточній версії неможливо на загальному рівні переспрямовувати усі запити до екземпляра Custodia. Замість цього слід визначати підрозділи для окремих ідентифікаторів користувачів, які переспрямовуватимуть запити до Custodia. У наведеному нижче прикладі проілюстровано конфігурацію, за якої запити користувача із UID 123 переспрямовуватимуться до Custodia, а запити усіх інших користувачів оброблятимуться локальним засобом надання даних.

[secrets]
[secrets/users/123]
provider = proxy
proxy_url = http://localhost:8080/secrets/
auth_type = header
auth_header_name = MYSECRETNAME
auth_header_value = mysecretkey


        

AUTHORS¶

Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/

NOTES¶

1.

custodia